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AN INFORMATION STORAGE SYSTEM 



FIELD OF THE INVENTION 

The present invention relates to an information storage system, and in particular to a 
5 process and system for storing information having a predetermined use which requires said 
information to be secured. 



BACKGROUND 

The secure storage of electronic information is a major concern for many organisations. In 
0 particular, the storage of customer information creates risks of privacy violations and theft 
of potentially valuable information. For example, many organisations store credit card 
information for their customers. The storage of a customer's credit card information 
obviates the need for the customer to re-enter the same credit card number, expiry date, 
and card name every time a credit card transaction is processed. Organisations with the 
5 ability to avoid this inconvenience and process transactions rapidly are likely to be more 
attractive to their customers. For example, the storage of credit card information enables 
the use of so-called 'one click' purchasing over the Internet, as described in US 5,960,41 1, 
increasing the completion rate of online purchases. Moreover, the storage of sensitive 
information such as credit card numbers avoids the need to re-transmit the information 
0 over potentially insecure communications networks, making it less vulnerable to theft 
during transmission, by transmission monitoring, for example. 

On the other hand, the storage of such information is unlikely to ever be totally secure, and 
the stored information is always at least potentially vulnerable to theft by hackers, 
malicious staff, contractors, cleaners, IT services suppliers, etc. This risk is always present 
5 for any organisation that keeps such information on record. The loss of such information is 
embarrassing and is potentially extremely costly for the organisation. It is desired to 
provide a process and system that alleviate the above difficulties, or at least provide a 
useful alternative. 




SUMMARY OF THE INVENTION 

In accordance with the present invention there is provided a process for storing information 
having a predetermined use which requires said information to be secured, including 
5 generating first data and second data from said information, such that said information can 
be generated from said first data and said second data, and said predetermined use cannot 
be performed using only one of said first data and said second data. 

Preferably, the process includes storing an identifier with said first data, and storing an 
1 0 encoded version of said identifier with said second data. 

Preferably, said first data and said second data are stored at respective locations physically 
remote from one another. 

1 5 Preferably, said encoded identifier includes a one-way hash of said identifier. 

Preferably, said hash is generated using an undisclosed hash function. 

Advantageously, the process may be executed by a client system, and may include: 
20 sending said first data and an identifier to a remote server for storage; and 

storing said second data and said identifier. 

Preferably, said step of sending includes sending said first data and said identifier to said 
remote server for storage, wherein an encoded identifier generated from said identifier is 
25 stored with said first data. 

Preferably, said encoded identifier includes a one-way hash of said identifier. 
Preferably, said hash is generated using an undisclosed hash function. 

30 
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Preferably, said hash is generated by a secure hash server remote from said client system 
and said server. 

Preferably, said process includes: 
5 receiving encoded first data; and 

generating encoded information from said encoded first data and said second data; 
and said step of storing includes storing said encoded information and said identifier. 

Preferably, said step of sending includes sending a message including said first data, said 
message including a digital signature of said client system and said message being 
1 0 encrypted with a public key of said remote server. 

Preferably, said step of receiving includes receiving a message including said encoded first 
data, said message including a digital signature and being encrypted with a public key of 
said client system. 

Advantageously, said information may include a credit card number. 
1 5 Advantageously, said information may include encrypted information. 

The present invention also provides a process for storing information, including: 

receiving an identifier and second data from a client system having first data, said 
first data and said second data being such that information having a predetermined use 
20 which requires said information to be secured can be generated from said first data and 
said second data, and said predetermined use cannot be performed using only one of said 
first data and said second data; and 

storing said second data with an encoded identifier generated from said identifier, 
and not storing said identifier. 



25 



Preferably, the process further includes: 

generating encoded second data from said second data; and 

sending said encoded second data to said client system for storage with said first 
data and said identifier. 
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The present invention also provides a process for generating information having a 
predetermined use which requires said information to be secured, including: 

determining first data of said information on the basis of an identifier, said first data 
being such that said predetermined use is infeasible with only said first data; 

determining second data of said information on the basis of an encoded identifier 
generated from said identifier, said second data being such that said predetermined use is 
infeasible with only said second data; and 

generating said information from said first data and said second data. 

Advantageously, said information may include encrypted information. 
Advantageously, said information may include a credit card number. 

Advantageously, said predetermined use may include processing a financial transaction on 
the basis of said credit card number. 

The present invention also provides a process for generating information having a 
predetermined use which requires said information to be secured, including: 

determining, on the basis of an identifier, first data of said information, said first 
data being such that said predetermined use is infeasible with only said first data; 

receiving said second data of said information from a remote server, said second 
data being such that said predetermined use is infeasible with only said second data; and 

generating said information from said first data and said second data. 

Preferably, the process includes sending said identifier to said remote server, and said step 
of receiving includes receiving, from said remote server, said second data determined on 
the basis of an encoded identifier generated from said identifier. 




The present invention also provides a process for generating information having a 
predetermined use which requires said information to be secured, including: 
receiving an identifier; 

determining second data of said information on the basis of an encoded identifier 
5 generated from said identifier, said second data being such that said predetermined use is 
infeasible with only said second data; and 

sending said second data to a client system to enable said information to be 
generated from said second data and first data of said information, said first data being 
such that said predetermined use is infeasible with only said first data. 

10 

Preferably, said step of receiving includes receiving said identifier from said client system. 

The present invention also provides a system having components for executing the steps of 
any one of the above processes. 

15 

The present invention also provides software having program code for executing the steps 
of any one of the above processes. 

The present invention also provides a computer readable storage medium having stored 
20 thereon program code for executing the steps of any one of the above processes. 

The present invention also provides a system for storing information having a 
predetermined use which requires said information to be secured, including: 

a client system for generating first data and second data from said information, 
25 such that said information can be generated from said first data and said second data, and 
said predetermined use is infeasible with only one of said first data and said second data, 
and for storing an identifier with said first data; and 

a remote server for storing said second data with an encoded identifier generated 
from said identifier. 



Preferably, said encoded identifier includes a hash value generated from said identifier. 
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Preferably, said system further includes a secure hash server for generating said hash value 
from said identifier, said secure hash server located remotely from said client system and 
said server. 

5 

Preferred embodiments of the present invention provide processes that allow an 
organisation to store only part of a customer's credit card number locally, sending the other 
part to a remotely located server for safe keeping. This reduces the risk of theft of the 
credit card number because neither the client system nor the server keeps a record of the 
10 entire number. Neither is the entire number ever transmitted in a single transmission 
between the client system and the server. 

When a charge needs to be applied to such a card, the two parts are extracted from the 
respective systems and then briefly united, solely for the purpose of sending a transaction 
to a banking system, and then the record of the full number is destroyed again. Thus the 
1 5 risk of credit card number theft is greatly reduced. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the present invention are hereinafter described, by way of 
example only, with reference to the accompanying drawings, wherein: 

Figure 1 is a schematic diagram of a preferred embodiment of an information 
storage system; 

Figure 2 is a block diagram of a client system of the information storage system; 
Figure 3 is a block diagram of an information server of the information storage 

system; 

Figure 4 is a flow diagram of an information storage client process executed by the 
client system; 

Figure 5 is a flow diagram of an information storage server process executed by the 
information server; 
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Figure 6 is a flow diagram of a first preferred embodiment of a transaction client 
process executed by the client system; 

Figure 7 is a flow diagram of a first preferred embodiment of a transaction server 
process executed by the information server; 
5 Figure 8 is a flow diagram of a second preferred embodiment of a transaction client 

process executed by the client system; 

Figure 9 is a flow diagram of a second preferred embodiment of a transaction 
server process executed by the information server; 

Figure 10 is a flow diagram of an information deletion client process executed by 
1 0 the client system; and 

Figure 1 1 is a flow diagram of an information deletion server process executed by 
the information server. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

1 5 As shown in Figure 1 , an information storage system includes an information server 1 02, a 
client system 104, a secure hash server 106, and a transaction server 108, interconnected 
by a communications network 1 10, such as the Internet. The client system 104 and servers 
102, 106, 108 are standard computer systems, such as Intel™-based personal computer 
systems running a Microsoft Windows™ operating system. However, to improve 

20 performance of the information storage system, the servers 102, 106, 108 can alternatively 
be high-performance network servers, such as Sun Fire™ servers available from Sun 
Microsystems, Inc™. As shown in Figure 2, the client system 104 includes client modules 
202, a customer database 204, and new customer data 206. The client system 104 
optionally includes transaction processing modules 208, as described below. As shown in 

25 Figure 3, the information server 102 includes server modules 302, and an information 
registry 304. The information server 102 optionally includes transaction processing 
modules 208. 



30 



The components 102 to 108 of the information storage system execute information storage 
processes that provide secure storage of sensitive or valuable information such as credit 
card numbers by dividing the information into two components such that the components 
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do not have individual worth or use value, and the information can only be put to it§ 
normal sensitive or valuable use when reassembled from the components. The 
components are stored separately at different physical locations, and are only reassembled 
when required for a predetermined use. The reassembled information is destroyed as soon 
5 as it has been used. In the case of a credit card number, this entails dividing the number 
into two portions, storing the components separately, and reassembling them to process a 
credit card transaction. As soon as the transaction details have been sent to an acquiring 
institution for completing the transaction, the reassembled number is destroyed. As neither 
portion of the credit card number can be used to process a financial transaction without the 
10 other portion, theft of a database containing either portion of the number is of little 
consequence unless the complementary portion is also obtained. Moreover, even if both 
databases are stolen, the components of a credit card number cannot be matched up 
because the components do not share any database keys, as described below. Furthermore, 
the thief must know how to generate the credit card number from its component portions. 

15 

In any case, the communication of each portion over the network 110 is digitally signed 
and encrypted using 128-bit encryption, making it infeasible to obtain any portion by 
eavesdropping on the communications. In the described embodiment, the information 
storage and transaction processes are implemented as software modules executed by the 
20 system components 102 to 108. However, it will be apparent that modules of the system 
may be distributed over a variety of locations, and that at least part of the modules may be 
implemented as dedicated hardware components, such as application-specific integrated 
circuits (ASICs). 

25 The client system 104 may be owned and operated by an organisation that wishes to 
maintain information on its customers, and, in particular, wishes to store credit card 
information for its customers. Customer information is typically maintained in a customer 
database, such as the customer database 204 stored on hard disk storage of the client 
system 104. The organisation stores this information in the database 204 using a unique 

30 customer number as a database key under which the information is stored. The 
information may include, for example, the customer's name, address, credit card 




9 



information, and account data, such as a standing transaction amount, as shown in the table 
below. 



10 



Customer number: 


1025543 


Standing transaction amount: 


$25 


Cardholder: 


Roger W Smith 


Card type: 


VISA 


Expiry date: 


05/03 


Card number: 


3647 3495 2341 1942 



Organisation-specific 
information 

Generic credit card 
information 



However, this customer data is vulnerable to theft, constituting a significant risk on the 
part of the customer and the organisation storing the data. To counter this risk, the 
information storage system divides sensitive information into at least two components. In 
the case of credit card information, the credit card number is divided into two portions. 
The credit card number is stored using an information storage process, comprising a client 
storage process of the client modules 202 executed by the client system 104 and a storage 
process of the server modules 302 executed by the information server 102, as described 
below. 



New customer information received by the organisation is received by the client system 
15 1 04, and stored as new customer data 206. For a new customer, this information typically 
includes personal details of the customer, including name, address, and credit card 
information. In the case of an existing customer of the organisation, the new customer data 
includes credit card information for a new credit card that the customer wishes to use when 
conducting financial transactions with the organisation. The credit card information is 
20 verified using standard verification techniques, which can include contacting credit 
agencies to ensure that the customer is not a bad credit risk. 

After the credit card details have been validated, the client system 104 executes a client 
information storage process, as shown in Figure 4. The process begins at step 402 by 
25 dividing the credit card number into two portions. In the described embodiment, a sixteen 
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15 



digit credit card number is split into two portions, comprising a first portion formed by the 
middle eight digits, and a second portion formed by the first four digits and the last four 
digits of the number. However, it will be apparent that the number can be divided in many 
ways, so long as this is known, as described below. At step 404, a message is constructed 
including a unique customer number assigned to the customer, and the first portion as 
follows: 



1025543 3495 2341 



At step 406, this message is digitally signed. To sign the message, a hash value is 
10 generated from the message content, and the resulting hash value is encrypted with a 
private encryption key of the client system 104. All encryptions are based on the standard 
RSA public key encryption scheme, described at http://www.rsa.com : however, it will be 
apparent that other encryption schemes can alternatively be used. The encrypted hash, 
being the signature of the client system 1 04, is added to the message, as follows: 



1025543 13495 2341 \ Signature of Client 



At step 408, the entire message is encrypted using a public encryption key of the 
information server- 102. This ensures that the message can only be decrypted by the 
information server 102. At step 410, the encrypted message is sent to the information 
20 server 102 using a suitable communications protocol, such as TCP/IP. At step 412, the 
process waits to receive a reply from the information server 102. 



As the client system 104 waits for the reply, the information server 102 executes an 
information storage server process, as shown in Figure 5. At step 502, the encrypted 
25 message sent from the client 104 is received by the information server 102. At step 504, 
the message is decrypted using the information server's private key. Once decrypted, the 
contents of the message are verified using the digital signature of the client system 104 at 
step 506. This includes decrypting the signature to obtain the hash value included in the 
message. The decryption process uses the client system's public key, which, assuming the 
client system 104 has not been compromised, confirms that the message originated from 
the client system 104. Then a hash value is generated from the message contents (ignoring 



30 
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the digital signature itself), and compared with the hash value received from the client 
system 104. If the two hash values are identical, this indicates that the message remains 
intact and has not been altered in transit or otherwise corrupted. The information server 
102 has now verified the message, and has the customer number and middle eight digits of 
the credit card number, as follows: 



1025543 



3495 2341 



At step 508, the customer number is hashed using the secure hash server 106. That is, the 
customer number is sent to the secure hash server 106 over the Internet 1 10 using TCP/IP. 
All communications between the information server 102 and the secure hash server 106 are 
digitally signed and encrypted, as described above, to further enhance security. The secure 
hash server 106 generates a hash value from the customer number using a robust one-way 
hash function known only to the secure hash server 106. For example, the secure hash 
server 106 could provide the following one way transformation between the customer 
number and a corresponding hash value: 



1025543 hashes to 2093 8408 



Hash functions that may be used include standard hash functions such as MD5, available 
from RS A at www.rsa.com, but the hash function is preferably a non-standard, undisclosed 
hash function so that even if both the client system 104 and the information server 102 
were compromised, a third party would still not be able to match records from the 
customer database 204 and the registry 304. Such a preferred hash function may be based 
on modifications of standard hash functions. For example, a hash function that first 
exchanges selected digits of the customer number and then uses this as input to an MD5 
hash function could be used. 

The resultant hash value is sent from the secure hash server 106 to the information server 
102, where it is used as a database key for storing the middle eight digits of the customer's 




credit card number. That is, the partial credit card number is stored in the registry 304, 
indexed by the hashed customer number, as follows: 



Key 


Data 


2093 8408 


3495 2341 



5 The secure hash server 106 is used rather than a hash function stored on the information 
server 102, in order to provide enhanced security by physically separating the hash 
function from the partial credit card storage. 



At step 514, the credit card digits are hashed using the secure hash server 106; for 
10 example: 



15 



| 3495 2341 hashes to 9394 2934 

At step 516, the hashed credit card digits are included in a reply message with the customer 
number. At step 518, this reply message is digitally signed. This includes creating a hash 
value for the customer number and hashed credit card digits, and encrypting the resulting 
hash value using the private key of the information server (IS) 102. The message then 
appears as follows: 



20 



1025543 



9394 2934 



Signature of IS 



At step 520, this message is encrypted with the client system's public key, and the 
encrypted reply is sent to the client system 104 at step 522. 



Returning to Figure 4, the received reply is decrypted using the client system's private key 
at step 414, and the message is verified, as described above, at step 416. At step 18, the 
encoded credit card digits included in the reply are combined with the second portion of 
the credit card number, to form an encoded, and presumably invalid, credit card number 
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for the customer. At step 420, the encoded number is stored in the customer database 204, 
indexed by the customer number as a database key, as follows: 



Customer number: 


1025543 


• • « 


• ■ • 


Card number: 


3647 9394 2934 1942 


• • • 


• • • 



Consequently, theft of the customer database 204 will not provide valid credit card 
numbers. 



Similarly, the registry 304 stored on the information server 102, appears as follows: 



Key 


Data 






2093 8408 


3495 2341 







As only the first portion of the credit card number is stored in the registry 304, theft of the 
registry 304 also does not provide credit card numbers. Moreover, because the registry 
304 is indexed by the hashed customer number, there is no direct apparent link between the 
credit card portion stored in the registry 304 and the complementary portions stored in the 
customer database 204. In order to reconstruct the credit card numbers, a thief would need 
to have access to the customer database 204, the registry 304, the hash function used by the 
secure hash server 106, and would need to know how to combine the two portions. 

Although the described embodiment includes dividing the credit card number in a 
relatively simple manner by extracting the middle eight digits, the credit card number 
could alternatively be divided in more complex ways by, for example, extracting every 
alternate digit. Moreover, this could be made even more complex by making the dividing 
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sequence essentially unique for each customer, such as by making it depend upon some 
other attribute of the customer information. For example, the credit card number could be 
divided by taking a pseudo-random sample of the digits derived from some other attribute, 
for example, the customer's birth date, or a hash of the customer's name, and so on. It will 
5 be apparent that many complex divisions can be used, making it extremely unlikely that a 
party having access to both databases would be able to reconstruct credit card numbers 
without also having access to the sequence generation process code. Consequently, the 
information storage system provides a greatly enhanced level of security over prior art 
storage systems. 

10 

The information server 102 may be owned and operated by the same organisation that 
owns and operates the client system 104, but may be alternatively owned by a second 
organisation that provides information storage services to client organisations for a fee. In 
order for the client organisation to make use of the customer credit card number, it must, of 

15 course, be reassembled at some point in order to process a credit card transaction. 
Transaction processing is performed using a transaction process, comprising a client 
transaction process of the client modules 202 executed by the client system 104, and a 
transaction server process of the server modules 302 executed by the information server 
102. Two preferred embodiments of the transaction process are provided, as described 

20 below. 

In a first preferred embodiment of the transaction process, the client system 104 executes a 
client transaction process, as shown in Figure 6. A customer of the organisation will have 
incurred charges, by ordering products, and/or services of the client organisation, for 

25 example. This might be achieved through a customer accessing a web server and 
transaction engine (not shown) of the client system 104 via the Internet 110, for example, 
or by some other standard method. The customer's transaction is initially identified by at 
least the customer's identification number and a transaction amount. The client transaction 
begins at step 602 when the encoded credit card number of the customer is retrieved from 

30 the customer database 204. At step 604, the encoded credit card number is split into two 
portions, the encoded portion, and the unencoded portion, as described above. At step 606, 




a message is created including the customer number, the hashed portion of the customer 
credit card number, and the unique transaction number assigned to the transaction, as 
follows: 



Customer Number 


False middle 8 


Transaction number 


1025543 


9394 2934 


99594 



The message is then digitally signed, encrypted with the public key of the information 
server 102, and sent to the information server 102, at steps 608 to 612, respectively. At 
step 614, the process waits to receive a reply from the information server 102. In the 
meantime, the information server 102 executes a server transaction process, as shown in 

10 Figure 7. After receiving the encrypted message at step 702, the message is decrypted with 
the information server 102's private key, at step 704, and the decrypted message is verified 
at step 706 using the client system 104's digital signature. At step 708, the customer 
number is hashed to generate a database key for the registry 304. At step 710, this key is 
used to retrieve the customer's credit card digits from the registry 304. At step 714, the 

15 retrieved partial credit card number is hashed, and at step 716, this is compared to the 
hashed value in the message. If, at step 718, these two values are not equal, then a reply 
message is created at step 720, containing an error code indicating that the customer data 
was not valid. Alternatively, if the values are equal, then a reply is generated including the 
partial credit card number and the unique transaction number, as follows: 

20 

3495 2341 99594 



In either case, the reply is digitally signed, encrypted using the public key of the client 
system 104, and sent to the client system 104, at steps 724 to 728, respectively. 

Returning to Figure 6, the reply is decrypted using the private key of the client system 104, 
and verified, at steps 616 and 618. If, at step 620, it is determined that the reply indicates 
an error, then at step 622 the transaction is denied and the error is processed, and the client 
transaction process then terminates. Alternatively, if the reply did not indicate an error, 
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then the transaction number in the reply is compared with the transaction number in the 
original message, to confirm that they are identical. If not, then at step 622 the transaction 
is again denied and the error is processed. Otherwise, at step 624 the transaction number 
returned in the reply is used to determine the corresponding request. (Although the client 
5 transaction process of Figure 6 is shown as a single process, the generation and sending of 
a request on the one hand and the processing of replies on the other hand can be executed 
as separate processes due to the latencies of the various components of the system.) 



At step 626, the customer's complete credit card number is reconstructed. At step 628, the 
10 transaction is processed using the transaction modules 208 of the client system 104. This 
requires transmission of the complete credit card number to the transaction server 108, 
which is owned and operated by a transaction acquirer, such as a bank. This 
communication of the complete credit card number is the only time that the complete 
number is transmitted by the information storage system. This transmission is preferably 
15 secured by including a digital signature of the client system 104, and encrypting the 
message with the public key of the transaction server 108, but can alternatively be secured 
by other methods used by the transaction acquirer. To further enhance security, ascending 
of the complete credit card number may be via a private network rather than a public 
communications network such as the Internet 110. 

20 

Once the transaction details have been sent to the transaction acquirer, the credit card 
number is destroyed at step 630, and the client transaction process ends. 

In a second preferred embodiment of the transaction process, the transaction processing is 
25 performed by the information server 102, rather than the client system 104. In this 
embodiment, the client system 104 executes a client transaction process as shown in Figure 
8. At step 802, the customer's encoded credit card number is retrieved from the database. 
At step 804, a message is constructed including the encoded credit card number, the 
customer number, and the transaction number as follows: 

30 



False Credit Card number 



Customer Number 



Transaction number 
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3647 9394 2934 1942 



1025543 



99594 



This message is then signed, encrypted, and sent to the information server 102 at steps 806 
to 810. While the client system 104 waits to receive a reply from the information server 
102 at step 812, the information server 102 executes a server transaction process, as shown 
in Figure 9. As in the first preferred embodiment, the message is received, decrypted, and 
verified at steps 902 to 906, and the customer number is hashed using the secure hash 
server 106, at step 908. At step 910, the resulting hash value is used as a database key for 
retrieving the middle eight digits of the customer's credit card number from the registry 
304, as follows: 



1025543 hashes to 2093 8408 



Key 


Data 


2093 8408 


3495 2341 



At step 912, these middle eight digits are hashed using the secure hash server 106, and at 
step 914, this hash value is compared with the hash value provided by the middle eight 
digits of the encoded credit card number included in the message received from the client 
system 104. If, at step 916, it is determined that the hash values are not equal, then at step 
918 a reply message is created, including an error code indicating that the customer data 
was not valid. Alternatively, if the values are equal, then at step 920 the customer's 
complete credit card number is reconstructed. At step 921, the transaction modules 208 of 
the information server 102 are used to send the transaction details, including the complete 
credit card number, to the transaction server 108 for final processing. At step 922, the 
reconstructed credit card number, having been used, is destroyed. At step 923, the 
transaction results are received from the transaction server 108. Alternatively, if the 
information server 102 is owned and operated by the same organisation that owns and 
operates the transaction server 108, then communication of the customer's complete credit 
number can be entirely within a secure internal network of the organisation. After the 
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transaction is complete, a reply message is constructed at step 924 including the 
transaction results, and the unique transaction number, as follows: 
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5 The reply is then digitally signed, encrypted with the client system's public key, and sent 
to the client system 104 at steps 926 to 930. 



Returning to Figure 8, the reply message is received at step 812, and is decrypted and 
verified at steps 814 and 816. At step 818, the transaction number included in the reply is 
10 used to identify the corresponding request, as described above. At step 820, the transaction 
results are processed as required. The transaction data can be keyed by the unique 
transaction number. Any interception of the reply message in and of itself provides 
insufficient information to be useful to a third party. Furthermore, the client system 104 
never has access to the complete credit card number. 

15 

It is sometimes necessary to delete a customer's credit card information from the 
information storage system, for example, if the customer cancels their account with the 
client organisation. This is achieved through an information deletion process, comprising 
a client deletion process executed by the client computer 104, and a server deletion process 

20 executed by the information server 102. In order to delete a customer's credit card 
information, the client system 104 executes a client deletion process, as shown in 
Figure 10. In order to delete a customer's credit card information, the customer number is 
provided to the process, and the customer's encoded credit card number is retrieved from 
the customer database at step 1002. At step 1004, a deletion request message is created 

25 including the customer number and the encoded digits of the customer's credit card 
number. At step 1006, the message is signed encrypted and sent to the information server 
102, as described above. The information server 102 executes a server deletion process, as 
shown in Figure 11. The information server 102 receives the deletion request message at 
step 1102. At step 1104, the message is decrypted and verified. At step 1106, the 

30 customer number included in the message is hashed using the secure hash server 106, and 
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at step 1 108, the hash value is used as a database key to retrieve the customer's credit card 
digits from the registry 304. At step 1110, these digits are hashed and the hash value is 
compared to the hash value included in the deletion request message. If, at step 1 1 12, the 
values are not found to be equal, then an error reply message is created at step 1114. 
5 Otherwise, at step 1116, the record in the registry 304 containing the customer's credit card 
digits is deleted, and at step 1118, a reply message is created indicating success of the 
deletion, and also including the customer number as follows: 



10 In either case, the reply message is signed and encrypted at step 1120, as described above. 
The encrypted message is sent to the client system 104 at step 1122. Returning to 
Figure 10, the reply message is received from the server 102 at step 1008. The message is 
decrypted and verified at step 1010. If, at step 1012, the message indicates that an error 
occurred, then the appropriate error processing is performed at step 1014, and the process 

15 ends. Otherwise, at step 1016, the customer's credit card information is removed from the 
customer database 204, and the process ends. 

Significantly, at no point in the deletion process does either the client server 104 or the 
information server 102 have access to the complete credit card number. Furthermore, 
20 interception of the messages between the client system 104 and the information server 102 
cannot be directly used to obtain a customer's credit card number. 

The information storage system provides a number of benefits, some of which have been 
discussed above. For example, although compromise of the information server 102 or the 

25 client system 104 could also compromise those customer credit card accounts that were 
charged (for compromise of the information server 102) or first entered (for compromise of 
the client system 104) during the period of compromise, this would still not compromise 
the credit card accounts of other customers, because at no point would all of the credit card 
information be compromised. Compromise of both the customer database 204 and the 

30 registry 304 does not compromise credit card numbers, because the secure hash server 106 
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is required to associate data records in the customer database 204 and the registry 304. 
Loss of the registry 304 would make it impossible to process transactions. For this reason, 
remote and secure mirroring of the registry 304 is preferred. Similarly, loss of the secure 
hash server 106 would make it impossible to process transactions. However, backups of 
5 the secure hash server 106 would address this issue. 

The system uses public key cryptography to render the links between the client system 104 
and servers 102, 106, 108 secure, so as to provide authentication of the sender and the 
integrity and privacy of the message. These safeguards are used because of the desirability 
10 of separating the two databases physically, and the attendant risk of compromise of 
communications. 

Although the preferred embodiments have been described above in terms of stored credit 
card numbers, it will be apparent that the system is applicable to any kind of information 

15 that meets a number of criteria. First, the information can be split into two or more parts, 
any of which is without value in the absence of the other or others. By way of example, it 
could not be used to protect a list of credit card numbers by splitting the list in two, 
because each part of the list, although not as long as the full list, would retain value 
regardless of the loss of the other. Secondly, the information must be able to be divided so 

20 as to make regeneration of any missing part implausible. The more difficult this 
regeneration, the better the protection. 

For example, a credit-card with 8 missing digits would be able to be regenerated using trial 
and error by cycling through all the possible combinations, but at one attempt per second, 

25 this would take over three years. A credit card number cannot be protected, however, by 
splitting off a single digit, because credit card numbers are formulated using a check-digit 
system, and a single missing digit can be re-generated from the other 15 digits. Another 
example: a credit-card expiry date would be protected only extremely weakly using this 
system. As a four digit quantity {e.g., 03/02) with only one bit of information in the first 

30 digit (always a 0 or a 1) and at most two bits in the fourth digit (because credit cards are 
typically issued to expire at most three years in the future), there are few possibilities. If 
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the first two digits are split away, there are at most four possibilities for the second two. If 
the first and the fourth are split off, there are only six possibilities. This four-digit quantity 
cannot be adequately protected using the information storage system. 

5 Nonetheless, many kinds of information are valuable and satisfy these criteria. For 
example, it can be used to securely store account numbers (e.g., bank account numbers), 
financial quantities (e.g., account balances), names (e.g., cardholder information, patient 
names), and so on. Moreover, the system can be used to protect multiple pieces of 
information in one application, for example, in the credit card example, protecting 
10 cardholder details in addition to the credit card number. 

Due to the seemingly arbitrary arrangements of numeric information (such as credit card 
and account numbers), they are well suited to division and separate storage. In contrast, 
textual and certain other kinds of information are not in general so well suited to division 

15 because each component may be 'readable' to some degree, depending upon how the 
information is divided. However, if the information is first scrambled or otherwise encoded 
in some manner that makes it unintelligible without the appropriate decoding step, then the 
system can be used to effectively divide and store the encoded information. Moreover, 
most encoding methods require the encoded information to be complete and intact in order 

20 to be decoded. In particular, an encrypted item of information, such as an encrypted 
document, cannot be decrypted if the encrypted document is not complete. Accordingly, a 
document could be encrypted and then divided into portions that are stored separately, as 
described above. 

25 This provides secure storage of documents with arbitrary content. It will be apparent that 
this process is not restricted to text documents, but can be used to securely store any type 
of information or data that can be represented electronically. 

Finally, the splitting into two components is simple and in most cases sufficient. However, 
30 it will be apparent that the system can be extended to divide information into more than 
two components, further reducing the risk of compromise by collusion. However, it will be 
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apparent that it is not necessary to use division at all. Any method that generates two or 
more components from input information, from which the input information can be re- 
generated, and where the components are not in themselves useful, valuable, or intelligible 
(as the case may be), can be used. 

Many modifications will be apparent to those skilled in the art without departing from the 
scope of the present invention as herein described with reference to the accompanying 
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